當實驗記錄本遇到流水線工廠

昨天我們學會了如何寫好「實驗記錄本」（Logging），記錄每次煉製的細節：AI 看到了什麼、說了什麼、花了多少時間和金錢。這就像一位獨自工作的煉金師，在工作檯前仔細記錄每個步驟。

但還記得 Day 14-16 我們聊過的 Multi-Agent 協作嗎？當你的煉金工房從單人作業變成了多人協作的流水線工廠時，問題就變得複雜了。

想像這個場景：使用者問了一個問題，系統花了 15 秒才回應。你打開日誌一看：

[14:30:15] Router Agent: 收到問題
[14:30:16] Research Agent: 開始搜尋
[14:30:25] Analysis Agent: 開始分析
[14:30:28] Writer Agent: 開始撰寫
[14:30:30] 回應完成

看起來很清楚？但你能回答這些問題嗎：

• 為什麼 Research Agent 花了 9 秒？ 它在等什麼？
• Analysis Agent 分析的是什麼資料？ 來自哪裡？
• 這 15 秒中哪個環節最慢？ 該優化哪裡？
• 這次請求總共花了多少錢？ 每個 Agent 各花多少？

光看日誌就像看一疊散落的照片，你知道每張照片發生了什麼，但不知道它們之間的關係。

這就是為什麼我們需要 Tracing（追蹤）——它不只記錄「發生了什麼」，更記錄「如何發生的」。

Tracing：你的包裹追蹤系統

最簡單的比喻就是物流追蹤。當你在網路上買東西，不是只想知道「包裹送達了」，而是想知道：

2024-10-09 10:00 【台北倉庫】包裹已出貨
2024-10-09 12:30 【桃園轉運站】包裹已到達，等待分揀
2024-10-09 13:15 【桃園轉運站】分揀完成，準備配送
2024-10-09 15:45 【配送中】司機已取件，預計 17:00 送達
2024-10-09 16:50 【已送達】包裹已簽收

這就是 Tracing 的精髓：追蹤一個請求的完整生命週期，記錄它經過的每個環節、花費的時間、遇到的狀況。

在 AI 系統中，Tracing 讓你看到：

• 使用者的問題如何從 Router Agent 傳到 Research Agent
• Research Agent 如何呼叫 RAG 系統檢索資料
• RAG 系統如何查詢向量資料庫
• 檢索到的資料如何傳給 Analysis Agent
• 最終如何由 Writer Agent 整合成回應

每個環節花了多少時間、用了多少 Token、遇到什麼問題，一目了然。

Distributed Tracing 的三個核心概念

概念一：Trace（追蹤）- 完整的故事

一個 Trace 代表一次完整的請求處理過程，從使用者發問到 AI 回應，中間經過的所有環節都屬於同一個 Trace。

就像一本小說，從開頭到結尾是一個完整的故事。

Trace ID: abc123
開始時間: 14:30:15
結束時間: 14:30:30
總耗時: 15 秒
狀態: 成功

概念二：Span（跨度）- 故事中的章節

一個 Trace 包含多個 Span，每個 Span 代表一個具體的操作或工作單元。

就像小說的章節，每章講述故事的一部分。

Span 1: Router Agent 處理
  開始: 14:30:15
  結束: 14:30:16
  耗時: 1 秒
  
Span 2: Research Agent 搜尋
  開始: 14:30:16
  結束: 14:30:25
  耗時: 9 秒
  子 Span:
    - RAG 檢索 (6 秒)
    - 網路搜尋 (3 秒)

Span 可以巢狀，就像章節可以有小節。這讓你能夠深入到任何層級的細節。

概念三：Context Propagation（上下文傳播）- 接力棒

當請求在不同的 Agent、不同的服務之間傳遞時，如何確保它們都屬於同一個 Trace？

答案是 Context Propagation——就像接力賽中的接力棒，確保每個選手都在跑同一場比賽。

# Router Agent 建立 Trace
trace_id = "abc123"
span_id = "span_001"

# 傳給 Research Agent
research_agent.process(
    trace_id=trace_id,
    parent_span_id=span_id
)

# Research Agent 繼續這個 Trace
def process(trace_id, parent_span_id):
    new_span_id = "span_002"
    # 這個 Span 的父節點是 span_001
    ...

透過傳遞 trace_id 和 parent_span_id，整個系統知道這些操作都屬於同一個請求。

RAG 系統的檢索路徑追蹤

還記得 Day 7 我們聊過的 RAG 系統嗎？檢索過程非常複雜，沒有 Tracing 根本不知道發生了什麼。

假設範例：

使用者問題：「公司的退貨政策是什麼？」
  └─ [Span 1] RAG 檢索流程 (總耗時 4.2s)
      ├─ [Span 2] 向量化問題 (0.3s)
      │   └─ [Span 3] Embedding API 呼叫 (0.25s)
      ├─ [Span 4] 第一階段：廣泛檢索 (1.5s)
      │   ├─ [Span 5] 向量資料庫查詢 (1.2s)
      │   │   - 查詢結果：找到 100 份文件
      │   └─ [Span 6] 關鍵字搜尋 (0.3s)
      │       - 查詢結果：找到 50 份文件
      ├─ [Span 7] 第二階段：重新排序 (1.8s)
      │   ├─ [Span 8] Cross-Encoder 模型 (1.5s)
      │   │   - 輸入：150 份候選文件
      │   │   - 輸出：前 10 份相關文件
      │   └─ [Span 9] CRAG 品質評估 (0.3s)
      │       - 評估結果：品質良好（Correct）
      └─ [Span 10] 知識精煉 (0.6s)
          - 最終提取：3 份最相關段落
          - Token 數：1,245

透過這個追蹤，你可以看到：

檢索了什麼：100 份向量搜尋 + 50 份關鍵字搜尋 = 150 份候選
花了多少時間：向量搜尋 1.2s、重新排序 1.5s
結果品質：CRAG 評估為「Correct」，不需要備用搜尋
最終使用：3 份段落，1,245 tokens

Day 7 我們學會了 RAG 的原理，Day 25 我們學會了如何追蹤它的執行過程。

成本追蹤：每個環節花了多少錢？

Day 22 我們聊過成本優化，但如果不知道錢花在哪裡，怎麼優化？

Tracing 可以追蹤每個 Span 的成本：

假設範例：

Trace ID: abc123
總成本: $0.245

  [Span 1] Coordinator Agent: $0.002
  [Span 2] Research Agent: $0.125
    [Span 3] RAG 檢索: $0.015
      - Embedding API: $0.001
      - 向量資料庫: $0.002
      - Reranking: $0.012
    [Span 7] 整理資料 LLM: $0.110 ← 最貴！
  [Span 9] Analysis Agent: $0.095
  [Span 12] Writer Agent: $0.023

發現了嗎？Research Agent 的「整理資料」這個步驟花了 $0.110，佔總成本的 45%！

為什麼這麼貴？追蹤顯示：

[Span 7] 整理資料
  輸入 Token: 25,000 (包含 100 份文件的內容)
  輸出 Token: 3,000
  模型: claude-sonnet-4.5
  成本: $0.110

原來是把 100 份文件的完整內容都傳給 LLM 了！Day 9 的 Context 管理策略告訴我們應該先做「Select」和「Compress」，而不是直接把所有資料丟進去。

有了 Tracing，你不只知道「系統很貴」，更知道「哪裡貴」和「為什麼貴」，才能精準優化。

工具推薦：煉金師的追蹤裝備

OpenTelemetry：業界標準

OpenTelemetry 是分散式追蹤的業界標準，就像 USB 是連接裝置的標準一樣。

優點：

• 開源且免費
• 支援所有主流程式語言
• 與各種監控平台整合（Datadog、New Relic、Honeycomb）
• 廠商中立，不會被綁定

LangSmith：專為 LLM 設計

LangChain 團隊開發的 LangSmith 專門為 LLM 應用設計，內建許多 AI 特有的追蹤功能。

優點：

• 自動追蹤 LangChain 應用（如果你用 LangChain）
• 內建 Prompt 版本管理
• 視覺化 Agent 協作流程
• 支援 A/B 測試和評估

適合：使用 LangChain 框架的團隊

Phoenix (Arize AI)：開源的 AI 觀測平台

Arize AI 的 Phoenix 是開源的 AI 觀測平台，專注於 LLM 應用的追蹤和評估。

優點：

• 完全開源免費
• 專為 LLM 設計的追蹤功能
• 內建幻覺偵測和評估
• 支援 OpenTelemetry 標準

適合：想要完全掌控資料的團隊

與前面章節的完美串聯

現在讓我們回顧一下，Tracing 如何與前面的章節串聯：

Day 7 的 RAG 系統：追蹤檢索路徑，找出哪個環節最慢
Day 9 的 Context 管理：追蹤每個 Context 策略的效果
Day 14-16 的 Multi-Agent：視覺化 Agent 協作流程
Day 22 的成本優化：追蹤每個環節的花費，精準優化

Tracing 不是獨立的功能，而是串聯整個系統的關鍵。它讓你從「知道出錯了」升級到「知道哪裡出錯」，從「系統很慢」升級到「這個環節最慢」，從「花費很高」升級到「這裡最貴」。

從黑盒子到透明工房

還記得我們在 Day 1 說過的「黑盒子」嗎？使用者問問題，AI 給答案，中間發生了什麼完全不知道。

經過 25 天的修練，我們一步步把黑盒子變透明了：

• Day 2-5：學會設計提示和管理 Context
• Day 6-9：掌握 Context Engineering 的完整框架
• Day 14-16：建立 Multi-Agent 協作系統
• Day 23-24：用 Logging 記錄發生了什麼
• Day 25：用 Tracing 追蹤如何發生的

明天，我們將探討最後一位好朋友：Metrics（指標）。如果 Logging 是「實驗記錄本」、Tracing 是「配方軌跡追蹤」，那 Metrics 就是「煉金工房的儀表板」——讓你一眼就知道系統的健康狀況。